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(54) A method for implementing a managed object in a network management system 



(57) The invention relates to a method for imple- 
menting a managed object in a subsystem of a man- 
aged system in a management network with at least 
one managing system and at least one managed sys- 
tem, for telecom or open systems, said managed sys- 
tem consisting of subsystems forming each a part of the 
managed system including one or more managed 
objects. 

The managed objects are implemented in the sub- 
system, uncoordinatedly with respect to other subsys- 
tems, in such a way that they can be connected to and 
transmit messages to other objects in other subsys- 
tems, and without knowing the type of objects in the 
other subsystems. This is obtained by designing a first 
object (330) for co-operation with an abstract object 
(332) defining an interface consisting of unimplemented 
methods, which may be called by the first object, and 
letting, at later design of a second object (334) unknown 
to said first object and intended to co-operate with the 
first object, the other object inherit the abstract object 
and implement the inherited methods, so that the first 
object at co-operation with the second object will con- 
sider it as being of said abstract type. 
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Description 

Technical field 

The present invention relates to a method for imple- 
menting a managed object in a management network 
with at least one managing system and at least one 
managed system, for telecom or open systems, said 
managed system consisting of subsystems forming 
each a part of the managed system including one or 
more managed objects. 

With a "management network with at least one 
managing system and at least one managed system" is 
meant that the management network can include at 
least one managing system which can manage one or 
more managed systems, which likewise can form part of 
the management network. 

With an open system is meant a system of the kind, 
which is defined in Reference Model of Open Systems 
Interconnection (OSI) for CCITT Applications, Rec. 
X.200. 

To perform management activities in a manage- 
ment domain there must be at least one manager which 
is responsible for the management of the resources. A 
resource is something which includes concepts and 
ability of the domain. An example of a domain is a tele- 
com network, where the resources are switches, trunks 
etc. and management units are e.g. operator tools and 
managing systems for the network. 

For operation of telephone networks each individ- 
ual company has used a number of different systems for 
operation and maintenance. CCITT has developed a 
standard model for operation and maintenance in tele- 
phone networks, called TMN (Telecommunication Man- 
agement Networks). The basic principle of TMN is to 
indicate an organized network structure, which admits 
connection of various managing systems to telecom 
equipment. This is achieved by use of standardized pro- 
tocols and interfaces. The telephone companies and 
other operators will require that future telecom networks 
are adapted to TMN. 

CCITT has a recommendation for this under devel- 
opment, the M.3000-serie. 

TMN considers all network nodes as network ele- 
ments (NE). These network elements are made as tele- 
phone switches and transmission or transport network 
products. 

The functional structure of TMN comprises 

management functions (OSR Operations Support 
Functions), which manage application programs 
available for users, such as management functions 
for "Business Management" and service and net- 
work administration; 

data communication functions (DCF; Data Commu- 
nications Functions), which manage data communi- 
cation between the managing systems OSS and 
the managed systems NE; 



mediation functions (MF, Mediation Functions), 
which convert information (between e.g. managed 
objects), manage data, concentrate, reduce and 
edit, make decisions relating to e.g. threshold limits 
5 and store data, which identify equipment and net- 

works; 

network element functions (NEF, Network Element 
Functions), which manage telecom processes as 
switching functions and transmission, and take part 

w in management processes for telecommunication, 
as fault localisation and protection connections; 
functions for interface adaption (QAF, Q-Adapter 
Functions), which perform conversion of interfaces 
from non standard to standard; 

75 - work station functions (WSF, Work Station Func- 
tions), which constitute the user terminals of TMN, 
show information and assist management techni- 
cians to manage the network. 

20 TMN also includes an interface, called Q3. Q3 is 
besides being a communication protocol also an infor- 
mation model, which comprises data schemes, opera- 
tions and notifications. The exact details of the Q3 
interface and its protocols appear from the CCITT rec- 

25 ommendations Q961 and Q962. 

TMN considers all physical and logical objects as 
managed objects, which in TMN are referred to as MO 
(Managed Objects), a denomination which will be used 
alternately also here henceforth. Managed objects are 

30 data images of such physical or logical resources as 
wires, circuits, signal terminals, transmission routes, 
events logs, alarm reports etc.. 

A specific relationship occurs between a resource 
and a managed object. A resource can be related to one 

35 or more MO or none at all. On the other hand an MO 
can be related to one or more resources or none at all. 
This relationship is important if an MO is affected by 
some form of operation or maintenance activity. An MO 
must not be removed before the functions to which it is 

40 subordinated have themselves been removed. This 
information model is based upon object orientation and 
the relation concept. 

The managing system (OSS- Operation Support 
system) treats network elements and subordinated 

45 managing systems as a collection of managed objects 
in an imagined data base MIB (Management Informa- 
tion Base). These managed objects are constituted by 
instances of an MO class, such as a number of signal 
terminals of the same type. Each terminal will thus con- 
50 stitute an instance of the class signal terminals. 

In TMN there also exists the concept MIM (Man- 
agement Information Model), which refers collectively to 
all information related to managed objects. MIM is a 
model of all attributes, relations, operations and notif ica- 

55 tions referable to managed objects. To be able to search 
for MO-instances a management information tree MIT 
(Management Information Tree) is used. This tree struc- 
ture starts in the network and indicates network ele- 
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merits and subscribers or equipment. 

For operation and maintenance each separate unit 
or resource, about which information is required, or the 
operation of which is influenced from the outside of the 
system, is represented by a managed object. Each 5 
information exchange referable to the management of 
operations or units, which must be influenced or which 
must report something (such as set up of data, assign- 
ment of name, or management of alarms) is done in the 
form of operations on, or notes from managed objects. 10 

A managed object includes attributes and can also 
have a relation to other managed objects. A number of 
different operations can be directed towards a managed 
object and events can be generated by such objects. 

Below an account of deficiencies of TMN will be is 
given. 

Network elements and subordinated managing sys- 
tems are managed by a managing system by means of 
operations towards the managed objects in the man- 
aged systems and supervision of notifications transmit- 20 
ted by the managed system. 

Allowed operations towards managed objects in the 
managed system are determined by an information 
model of the managed system, together with the notifi- 
cations, which can be transmitted. The information 25 
model states: 

which classes of managed objects that are defined, 
which operations the managed objects in these 
classes accept, 30 
which notifications that the managed objects are 
expected to transmit, 

how many instances that can be created or 
removed, in each class of managed objects, 
dependences between managed objects, e.g. that 35 
one managed object requires existence of another 
one, 

dependences in a managed object, e.g. that a spe- 
cific attribute value of one attribute is only allowed if 
another attribute is set to a specific value or if the 40 
managed object only can be removed if it is in a 
specific state, 

the purpose and intention with managed objects 
and their notifications. 

45 

To be meaningful the managing system must know 
the information model of the managed system. This is in 
TMN called "shared management knowledge". 

At a change of the information model the manage- 
ment model must be updated in accordance with this so 
change. In conventional systems these changes are 
made by: 



Definition of the new information model. This is 
made by specifications for managed objects written 
as GDMO/ASN.1 templates (GDMO - Guidelines 
for the Definition of Managed Objects according to 
CCITT rec. X.722 ISO/IEC 10165-4) and ER-dia- 



55 



grams (Entity-Relationship diagrams) for the man- 
aged objects. The specifications for the managed 
objects state formally (machine readable) syntax 
(e.g. operations and notifications) for the managed 
object. 

All other parts of the information model, as depend- 
ences, the number of instances etc., are stated infor- 
mally as comments in natural language. 

Implementation and verification of the new informa- 
tion model in the managing system and the man- 
aged system. 

Confirmation that the managing system and the 
managed systems are adapted to the same infor- 
mation model by performing accepted test 
sequences. 

Updating of the network consisting of the managing 
system and the managed system with this new ver- 
sion of the information model. 

That just mentioned above results in a number of 
problems: 

Firstly, the development of managing systems and 
managed systems must be coordinated, which 
leads to higher development costs and/or a delayed 
introduction of new services on the market. 
Secondly, the absence of formalism with respect to 
the specifications of the managed systems, makes 
implementation, verification and acceptance of both 
managing system and managed systems to a diffi- 
cult and time demanding task, since the interpreta- 
tion of the specifications is open to discussion. 
Thirdly, updating of networks must be planned and 
carried out carefully, as there are dependences 
between different versions of the managing sys- 
tems and managed systems. This involves a 
delayed introduction of new services in the network. 

The purpose of management according to the TMN 
model is to be a framework for standardization of man- 
agement for telecom networks and open systems. The 
management structure strongly influences the manage- 
ment paradigm for new system architectures. There are 
strong reasons to assume the management paradigm 
according to the TMN model for the whole management 
and not only for domains subjected to standardization. 
The main reason for this is that it is desirable to be able 
to develop and design management functions in a uni- 
form way. 

Summary of the invention 

It is a purpose of the invention to design a managed 
object, which should be able to communicate with 
unknown future objects, it should be possible for the 
original object to be related to and to co-operate with an 
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unknown object without modification, or even reloading 
of the original object. 

Said purpose is attained by the method defined by 
way of introduction being characterized in that the man- 
aged objects are implemented in the subsystem, unco- 
ordinatedly with respect to other subsystems, in a way 
that they can be connected to and transmit messages to 
other objects in other subsystems, and without knowing 
the type of objects in the other subsystems, by design- 
ing a first object for co-operation with an abstract object 
defining an interface consisting of unimplemented 
methods, which may be called by the first object, and 
having, at later design of a second object unknown to 
said first object and intended to co-operate with the first 
object, the second object to inherit the abstract object 
and implement the inherited methods, so that the first 
object at co-operation with the second object will con- 
sider it as being of said abstract type. 

Advantageous embodiments of the invention have 
obtained the characterizing features stated in the 
respective dependent claims. 

Description of the drawings. 

A number of embodiments of the invention will now 
be described below in greater detail with reference to 
the enclosed drawings, on which 

Figures 1-9 in block diagrams illustrate problems, 
which can appear at the use of technology accord- 
ing to the state of the art in connection with the 
design of managing systems, where 
Figures 1 -4 concern problems, which can appear in 
connection with reuse of library components in the 
managed objects in managed systems, 
Figures 5 and 6 refer to problems, which can 
appear at the implementation of a managed system 
in a layered system architecture, 
Figures 7-10 illustrate how the problems according 
to Figures 1 -6 can be generally solved by design of 
a specific type of object, which should be able to co- 
operate with unknown future managed objects, 
Figures 11-14 specify design of objects according 
to Figures 10-14, the object type being assumed to 
belong to a platform system, 
Figures 1 5-20 show the implementation in the pro- 
gram code C++ of dependences between the 
designed objects according to Figures 11-14. 

Description of embodiments 

A managed system consists of several subsystems, 
more exactly a system platform and a number of appli- 
cations. According to the invention these subsystems 
are developed uncoordinatedly and are loaded sepa- 
rately. 

At the development of an application - or a system 
platform - there are libraries with reusable components. 



These components should be incorporated and com- 
bined in different ways in the different subsystems. 

The two different problems described above have 
certain properties in common. There are system com- 

5 ponents, which are developed uncoordinatedly, but still 
there are dependences between the components. To 
keep such dependences it is necessary that the compo- 
nents should be able to communicate with other compo- 
nents which are separately developed and even loaded. 

w The design process described below in greater 
detail is usable in two different contexts with similar 
problems. 

The first problem refers to reuse of library compo- 
nents. 

is At design of a managed system there are libraries 
with reusable components, which can be incorporated 
in the objects of the managed system. As is illustrated in 
Figure 1 there are first a main library 260 including com- 
ponents with basic functionality, such as MOstateCom- 

20 ponent 262 and WorkingStateComponent 264. These 
components include state attributes common to many 
different types of managed objects. The functionality of 
these basic components is reused by other components 
with a more specialized functionality. In the traffic man- 

25 agement library 266 there is e.g. a StatePropagation- 
Component 268, which has the ability to transfer state 
transitions in MOstateComponent 262 to the related 
dependent object 270. 

It should be emphasized that components as well 

30 as the managed objects are supposed to be imple- 
mented in an object oriented language. Both the com- 
ponents and the managed objects are thus really 
objects. But the components can not exist as identifiable 
objects by themselves in an application. They can only 

35 form a part of managed objects. 

A straightforward way to implement components, 
which depend on other basic components, e.g. the com- 
ponents in the fault handling and the traffic manage- 
ment libraries in Figure 1, is to include the basic 

40 components either by heritage or aggregating. This 
causes however many problems. This depends upon 
the fact that several components, e.g. FaultHandling- 
Component 272 and ResourceManagementCompo- 
nent 274, which inherit or aggregate the same basic 

45 component, e.g. MOstateComponent 262, can be 
included in the same managed object- Route 276, com- 
pare Figure 2. This implies that there will be several 
copies of the basic component in the managed object, 
which will cause consistency problems if the basic com- 

so ponent includes data, which is visible external to the 
components. Data of MOstateComponent should in 
other words be available for another functionality in the 
managed object than those components in which 
MOstateComponent is included. 

55 There is a way to avoid the problem described 
above. 

MOstateComponent should not be inherited or 
aggregated in components which depend on this com- 
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ponent. Instead the dependent components should 
include reference attributes to MOstateComponent 
Thus the latter will be a component of its own in those 
objects in which it is included. Components which need 
to access MOstateComponent will then each include a 
reference to the same instance of the MO-state compo- 
nent, compare Figure 3. 

As has been mentioned earlier a component, such 
as ResourceManagementComponent 274 and Fault- 
HandlingComponent 272, can include a functionality 
which is triggered by state changes in MOstateCompo- 
nent 262. The latter must therefore be able to transmit 
state change messages to other components. One 
problem is however that the receivers of these mes- 
sages are unknown at the design of MOstateCompo- 
nent. MOstateComponent 262 must in some way be 
able to communicate, cf. arrows 280, 282, with an arbi- 
trary later appearing component, compare Figure 4. 

The second problem refers to a layered system 
architecture. 

A managed system can be implemented in a lay- 
ered architecture. More exactly, there are system plat- 
forms with basic functions, which can be reused by 
different applications, compare Figure 5. The system 
platform 290 i.a. includes different kinds of common tel- 
ecom services. The application can thus delegate many 
tasks to the system platform. The system platform 290 
and the applications 292 are loaded separately. It must 
be possible to load an application and link it to the sys- 
tem platform without reloading the platform. 

Both the system platform 290 and the applications 
292 include managed objects. The objects 294 and 296 
in the platform 290 can e.g. represent resources, as 
switches, transmission routes, trunks etc. The objects 
298,300 and 302,304 in the applications 292.1 resp 
292.2 can be related to and co-operate with the 
resources in the system platform, compare Figure 6. An 
object in an application can delegate some tasks to an 
object in the system platform. Objects in the applica- 
tions may thus depend on related objects in the system 
platform to be able to work. As the system platform is 
known at the development of an application it is no prob- 
lem to design the objects in the applications for commu- 
nicating with the objects in the system platform. As has 
been mentioned earlier the objects in the applications 
can however be dependent on the objects in the system 
platform. This implies that objects in the system plat- 
form should be able to transfer state changes, as has 
been described earlier above, to objects in the applica- 
tions. This implies that objects in the platform should be 
able to be related to and take initiative to calling objects, 
which are unknown at the design of the platform sys- 
tem. 

Above two cases with similar problems have been 
described. Here will now follow a description of how 
these problems can be solved. 

More exactly, the real problem in each of the two 
cases is to design an object, which should be able to 



communicate with unknown future objects. It must be 
possible for the original object to be related to and to co- 
operate with an unknown object without modification, or 
even reloading of the original object. 

s This problem can be solved with the design princi- 

ple illustrated in Figure 7. The original object 330 is 
designed to co-operate with an abstract object 332. The 
abstract object defines an interface consisting of unim- 
plemented methods. These are the methods, which can 

10 be called by the original object. At the design of an 
object 334 designated to co-operate with the original 
object it must inherit the abstract object 332 and imple- 
ment its inherited methods. At the co-operation with an 
unknown type of object the original object 330 will con- 

75 sider this as being said abstract type 332. At call of a 
method defined in the interface of the abstract object 
332 the call will be delegated to implementation in the 
real object 330 via late binding. 

Avoidance of reloading of the original object at load- 

20 ing of the future objects is achieved by dynamic linking. 
Figure 8 illustrates how the just described design 
can be used for the design of basic library components. 
MOstateComponent 340 is designed to communicate 
with objects, which inherit an abstract object: 

25 MOstateSubscriber 342. This abstract object defines 
methods called by MOstateComponent when a state 
change occurs. If a component should subscribe to 
state changes in MOstateComponent, it must inherit 
MOstateSubscriber 342 and implement the answer to 

30 the respective state transition notifications. The sub- 
scribing component must of course also state itself as a 
subscriber to MOstateComponent. 

The principles of design described with reference to 
Figure 7 can also be used for designing objects in a sys- 

35 tern platform to co-operate with application specific 
objects. This is illustrated in Figure 9, where object 
PlatformObjectl 350 is designed to co-operate with 
object 352 in application system 354. An object in an 
application, which should co-operate with the object 

40 Platformobjectl 350 must inherit the abstract object 
Interfaceobject 356. Further there is a data base rela- 
tionship between PlatformObjectl 350 and InterfaceOb- 
ject 356. This implies that the objects which inherit 
InterfaceObject 356 can set up relations with 

45 PlatformObjectl 350. To make it possible to load appli- 
cations without reloading of the system platform 
dynamic linking is used. - 

Often an object in an application system is state 
dependent of another object in the system platform. 

so This design makes it possible to implement such state 
dependences in essentially the same way as for objects 
which are known to each other when they are imple- 
mented, as will be described in greater detail further 
below. 

55 Dependences between uncoordinated objects can 
be specified and implemented in essentially the same 
way as between coordinated objects, which has been 
described earlier above. Here the same examples will 
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be used to show the design and implementation of 
dependences between uncoordinated objects. It is how- 
ever assumed here that the object type ResourceB 
belongs to a platform system. Thus, with reference to 
Figure 10, various kinds of objects in various application 
systems can be related to and co-operate with the 
object ResourceB 370. The object type ResourceB 370 
is related to UserObject 372 via a data base relation- 
ship. Resource A 374 inherits UserObject 372 to be able 
to be related to ResourceB 370. !n the following it will be 
shown how these objects are specified and imple- 
mented. The same pseudo syntax as above will be 
used. 

The specification of the object ResourceB is found 
in Figure 11. The specification includes two state 
attributes: admState and opState, a method to allocate 
instances of ResourceB and a precondition which 
states that to enable erase of a ResourceB object it 
must be locked. This is essentially the same as earlier. 
The only difference is that in this example ResourceB is 
related to UserObject instead of ResourceA. The rela- 
tion is established via a reference attribute userRef, line 
6. 

In Figure 12 the object UserObject is specified. It 
includes the state attribute admState. It can however be 
noted that this attribute is specified as being purely vir- 
tual, line 19. This implies that the UserObject in fact will 
not include the attribute admState. The interface of Use- 
rObject will however include unimplemented write and 
read methods for this attribute. The real implementation 
of these virtual methods will appear in the respective 
subtypes of UserObject. Besides there are another 
attribute resourceBstate, which is assumed to keep the 
value of opState in the related object ResourceB. Fur- 
ther, the UserObject has a reference attribute Bref, 
which is used to establish relations with objects of the 
type resourceB, line 21 . 

A dependence scheme, which specifies end condi- 
tions, including both the object UserObject and the 
object ResourceB is found in Figure 13. There is an end 
condition, lines 29-31, which states that admState of 
UserObject depends on admState in ResourceB in such 
a way that an object UserObject can not be locked up if 
the related object ResourceB is locked. 

In Figure 13 it is further specified that when a value 
of opState in an object ResourceB is changed, the new 
value should be propagated to the related instance of 
UserObject. In Figure 13 there is no end condition spec- 
ified which relates to opState, it is only stated that 
changes of opState in ResourceB should be propa- 
gated to the attribute resourceBstate in UserObject, 
lines 36 and 37. This implies that all subtypes of Use- 
rObject are not necessarily opState dependent on 
ResourceB, but each subtype of UserObject can man- 
age the opState dependence of ResourceB in its own 
way. 

In Figure 14 the specification of ResourceA is 
shown. ResourceA is specified as being a subtype of 



UserObject (line 41). This implies that ResourceA inher- 
its the attributes, methods, conditions and the propaga- 
tions in UserObject. All the purely virtual specifications 
in UserObject must be specified and implemented in 

s ResourceA. As appears from Figure 7 the value of 
opState in ResourceA is derived from the attributes 
internalOpState and resourceBstate (which is inherited 
from UserObject), lines 46-49. 

As has been mentioned earlier the implementation 

10 is essentially the same as when the objects belong to 
the same system. The difference is that a certain part of 
the functionality of the dependent object which uses 
ResourceB is implemented in UserObject. As earlier the 
code can automatically be generated from the specif ica- 

75 tions by a compiler. The declaration file which is gener- 
ated from the specification of UserObject in Figure 12 is 
found in Figure 15. 

The method checkConsistency in UserObject 
checks the dependence between the admState 

20 attributes, which are stated in the dependence scheme 
in Figure 13. The implementation of this method is 
shown in Figure 16. To check this condition the value of 
admState in UserObject must be read. This explains 
why there must be a purely virtual specification of adm- 

25 State in UserObject, even if this attribute is not really 
included in UserObject. 

The declaration file which is generated by the spec- 
ification of ResourceB in Figure 1 1 is found in Figure 1 7. 
The implementation of the method propagateOpstate is 

30 however somewhat different, compare Figure 8. The 
new value is propagated to the attribute ResourceB- 
state in the related userObject instance. The admState 
dependence between UserObject and ResourceB must 
be checked at updating of the object ResourceB as well 

35 as at updating of UserObject instances. Therefore, this 
condition is implemented in the method checkConsist- 
ency in ResourceB. 

Figure 9 shows the declaration file, which is gener- 
ated from the specification of ResourceA. The opState 

40 dependence of ResourceB is implemented by deriva- 
tion of the value of opState from resourceBstate and 
internalOpState, compare Figure 20. 

The advantages of the above described are the fol- 
lowing. 

45 Dependences and co-operation between uncoordi- 
nated objects can be specified and implemented in the 
same way as dependences- between objects in the 
same subsystem. This implies that they are visible to 
and can be interpreted by a managing system. 

so The above illustrated process for maintenance of 
dependences between uncoordinated objects in a con- 
trolled and visible way facilitates implementation of a 
determinable management model in a layered architec- 
ture. 

55 The degree of reuseability of the library compo- 
nents can be improved by a high degree of flexibility 
when combinations of components are concerned. 



6 



11 



EPO 817 422 A2 



Claims 

1 . A method for implementing a managed object in a 
subsystem of a managed system in a management 
network with at least one managing system and at s 
least one managed system, for telecom or open 
systems, said managed system consisting of sub- 
systems forming each a part of the managed sys- 
tem including one or more managed objects, 
characterized by implementing the managed 10 
objects in the subsystem, uncoordinatedly with 
respect to other subsystems, in such a way that 
they can be connected to and transmit messages to 
other objects in other subsystems, and without 
knowing the type of objects in the other subsys- is 
terns, by designing a first object (330) for co-opera- 
tion with an abstract object (332) defining an 
interface consisting of unimplemented methods, 
which may be called by the first object, and letting, 

at later design of a second object (334) unknown to 20 
said first object and intended to co-operate with the 
first object, the other object inherit the abstract 
object and implement the inherited methods, so 
that the first object at co-operation with the second 
object will consider it as being of said abstract type. 25 

2. A method according to claim 1 , characterized by 
delegating, at call of a method defined in the inter- 
face of the abstract object, the call to the implemen- 
tation in the real object by means of late binding. 30 

3. A method according to claims 1 or 2, characterized 
by reloading, in case of loading of said second 
object, said first object in the managed system by 
means of dynamic linking between the respective 35 
subsystems. 

4. A method according to any of claims 1 -3, character- 
ized by locating said first and second objects in first 
and second subsystems, respectively. «> 

5. A method according to claim 4, characterized by 
using dynamic linking to enable loading in the man- 
aged system of said second subsystem without 
reloading of said first subsystem. 45 



55 



EPO 817 422 A2 



Fig.l 



262 



Basic Support Library 



MOstate 
Component 



WorkingState 
Component 




266 



Fault Management Library 

y _ l 



Fault 

Handling 

Component 

=£3 



Repair 
Handling 
Component 



Traffic Support Library 






Resource 




State 




Management 




Propagation 




Component 




Component 




/ / ... 


At* 



272 




21U 



Application System / 

\\/ / 


^ Route 




Trunk 






l 268 



,270. 



Inclusion 



Route 



276 



Fig.2 



-272 



27^- 



FaultHandling 
Component 



MOstate 
Component 



262 



ResourceManagement 
Component 



MOstate 
Component 



8 



EP 0 817 422 A2 



Fig. 3 



Route 



27o - 



FaultHandling 
Component 



in 



MOstate 
Component 



Resource 

Management 

Component 



11U 



262 



Reference 



Fig. 4 



Route 



FaultHandling 
Component 



272 



280 



Resource 
Management 
Component 




t 



11U 



MOstate , 
Component 



■262 



Fig. 5 




API 




9 



EPO 817 422 A2 



Application System A 



Application 
Object 1 



298 



Application 
Object 2 



300 



Fig. 6 

- -292.1 
292.2" 

302- 



Application System B 



Application 
Object 3 



7 



\ 



/ 



Application 
Object 4 

=23 



\ 



/ 



/ 



/ 



interaction and 
relations 

■\ 



/ 



/ 



System Platform ^ 

/ \ 



/ 1^290 



Platform 




Platform - 




-2% 


Object 1 




Object 2 







29^ 



^304 



330 



Fig. 7 



Original 
Object 


messages 


Abstract 

Interface 

Object 





Future 
Object 



332 




10 



EP 0 817 422 A2 



Fig. 8 



Basic Support Library 



MOstate 




Component 





340" 



MGSS9Q6S 



MOstate 
Subscriber 

e=2 



I c 



342 
isA 



Traffic Support Library i 






State 




Resource 




Propagation 




Management 




Component 




Component 





Fig.9 



354- 



/Application System 



352- 



/Application 
Object 1 I 



isA 



Messages 



System Platform 



356' 



JL 



Interface 
Object 



Messages 



Oatab. 
rel. 



Platform 
Object 1 



350 



Fig. 10 



Application System 



Resource A 



374 



I isA 



System Platform 



User 


userRef 


ResourceB 


Object. 


--372 370~- 





11 



EP 0 81 7 422 A2 



Fig. 11 



1 OBJECT TYPE ResourceB IS 

2 ATTRIBUTES 

3 key : KeyType; 

4 admState : Adminis t rat i veSt ate ; 

5 opState : Operat ionalSt ate ; 

6 userRef : REFERENCE TO UserObject 

INVERSE OF Bref; 

7 PRIMARY KEY key; 
8 

9 METHODS 

10 allocateO RETURNS Boolean; 
11 

12 PRE-CONDITIONS 

13 deleteObj ect ( ) ONLY IF 
admState = locked; 

14 

15 PARTY TO ResourceAndUser ; 

16END ; 



Fig. 12 



170BJECT TYPE UserObject IS 

18 ATTRIBUTES 

19 admState : Admin i s t r a t i v e S t a t e , 

PURE VIRTUAL; 

20 resourceBstate : Operat ionalState; 

21 Bref : REFERENCE TO ResourceB 

INVERSE OF UserRef; 

22 

23 PARTY TO ResourceAndUser; 
24END ; 
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Fig. 13 



25DEPENDENCY SCHEMA ResourceAndUser IS 

26 FOR ALL UserObject (a) , ResourceB(b) ; 

27 RELATIONS a.Bref = b; 
28 

29 POST-CONDITIONS 

30 NOT (a.admState = unlocked AND 

31 b.admState = locked) 

32 RULES 

33 WHEN COMMIT THEN CHECK CONSISTENCY; 
34 

35 PROPAGATIONS 

36 WHEN b.opState = NewValue 

37 THEN CONCLUDE a . resourceBstate=NewValue ; 
38 

39END; 



Fig. 14 

400BJECT TYPE ResourceA IS 

41 BASE UserObject; 

42 

43 ATTRIBUTES 

44 key : Key Type; 

45 admState : Admin i s t ra t i v eS t a t e ; 

46 OERIVEO opState = IF ( InternalOpStat e=disabled OR 

47 re s our ceB s t a t e = disa b 1 e d ) 

48 THEN disabled 

49 ELSE enabled; 
50 

51 internalOpState : OperationalState PRIVATE; 
52 

53 PRIMARY KEY key; 
54 

55 METHODS 

56 allocate() RETURNS Boolean; 
57 

58 PRE-CONDITIONS 

59 deleteOblect ( ) ONLY IF admState = locked; 
60 

61 POST-CONDITIONS 

62 NOT (admState = unlocked ANO Bref = NULL) ; 
63 

64END; 
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65 


ifndef UserOb j ect_hh_ 


66 


define UserOb j ect_hh_ 


67 




68 


include <Predef inedTypes . hh> 


69 


include "MOstateTy pes . hh " 


70 




71class ResourceB 


72 




73// OBJECT Type Userobject 


74 




75class Userobject 


76( 




77public 


78 


static UserObject* open (Mode , const 


79 


KeyType&, DbTransaction* transaction= 




NULL) ; 


80 


virtual deleteOb j ect ( ) =0; 


81 


virtual Boolean checkConsistency 




( ErrorMessageS) ; 


82 




83 


virtual AdministrativeState 




getAdmSt ate ( ) =0; 


84 


virtual void setAdmState 




(const Administrati veSt ate) == ; 


85 


OperationalState getResourceBst ate ( ) ; 


86 


setResourceBstate (const 




OperationalState) ; 


87 


ResourceB* getBref(); 


88 


void setBref (ResourceB*) ; 


89 




90privat e : 


91 




92 




93) 


f 


94 




95 


endif 
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97 include "UserObj ect . hh" 

98 include "ResourceB.hh" 
99 

100//////////////////// 
101// 

102// UserObject: METHOD checkConsistency 

103// 

104 

lOSBoolean UserObject: : checkConsistency ( 
ErrorMessageS message) 

106 ( 

107 Boolean flag = true; 
108 

109 flag = ! (getAdmState ( ) unlocked && 

110 getBref ( ) ->get a dmS t a t e ( ) = = 1 oc k e d ) ; 

111 if ( !flag) ( 

112 createErrorMessage ( 1 , message) ; 

113 ) 

114 return flag; 
115) 

116 
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ResourceB hh 
~~ TTesourceB Tnh 



<Predefined Types. hh> 
" MOst ateTypes . hh " 



117 ifndef 

118 define 
119 

120 include 

121 include 
122 

123class UserObject; 
124 

125// OBJECT TYPE Resources 
126 

127class ResourceB 
128( 

129public 
130 
131 
132 
133 
134 



135 
136 
137 
138 



void deletob j ect ( ) ; 

void deleteOb j ect ( ) ; 
Boolean allocated ; 
virtual Boolean checkConsistency 
( ErrorMessageS) ; 

KeyType getKey ( ) ; 

AdministrativeState getAdmStat e ( ) ; 
void setAdmState (const 
AdministrativeState) ; 
OperationalSt ate getOpSt ate( ) ; 
void setOpState (const OperationalState) 
UserObject* getUserRef ( ) ; 
void setUserRef (UserOb j ect * ) ; 



139 
140 
141 
142 
143 

144pr ivate 



145 

146 

147 

148 

149) 

150 

151 



void prop agat eOpSt at e 
(const OperationalState); 
void opState (const OperationalState) 



endif 



16 



EP 0 817 422 A2 



Fig. 18 

153 include "ResourceB.hh" 

154 include "UserOb j ect . hh " 
155 

156////////////////////// 

158// Resources: METHOD setOpState 

159// 

160 

161void ResourceB: :setOpState( 

const Operat ionalSt at e newValue) 

162( 

163 OperationalState oldValue = getOpSt at e ( ) ; 
164 

165 opState (newValue) ; 

166 if (newValue != oldValue) 

167 ( 

168 propagateOpState (newValue) ; 

169 ) 
170) 
171 

172///////////////////////// 
173// 

174// ResourceB: METHOD PropagateOpState 

175// 

176 

177void ResourceB: : propagateOpSt ate ( 

const OperationalState newValue) 

178( 

179 getUserRef ()->resourceBstate (newValue) 
180) 

181 
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Fig. 19 

182 ifndef _ResourceA_hh_ 

183 define _ResourceA_hh_ 
184 

185 include <Predef inedTy pes . hh> 

186 include " UserOb j ect . hh " 
187 

188// OBJECT TYPE ResourceA 
189 

190class ResourceA : public UserObject 
191 ( 

192public 

193 static ResourceA* open(Mode, 

194 const KeyType&, DbTransaction* 
transact ion=NULL ) ; 

195 void deleteObject (); 

196 virtual Boolean checkConsistency 
( ErrorMessageS) ; 

197 

198 Boolean allocate(); 
199 

200 KeyType getKey ( ) ; 

201 AdministrativeSt ate get AdmSt ate ( ) ; 

202 void setAdmState (const 
AdministrativeSt ate ) ; 

203 OperationalState getOpSt ate ( ) ; 
204 

205privat e 

206 OperationalState getlnternalOpState ( ) ; 

207 void setlnternalOpState (const 
OperationalState) ; 

208 

209 

210) ; 

211 

212 endif 

213 
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Fig.20 



214 include " Re sourceA . hh " 
215 

216///////////////////// 

217// „ + 

218// ResourceA: METHOD getOpState 

219// 

22 0 

2210perationalState ResourceA: : getOpSt ate ( ) 
2 2 2 ( 

223 if (get InternalOpStateO ==disabled 

224 getResourceBstate ( ) ==disabled) 

225 ( 

226 return disabled; 

227 ) 

228 else 

229 ( 

230 return enabled; 

231 ) 

23 2) 

23 3 — 
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(57) The invention relates to a method for imple- 
menting a managed object in a subsystem of a man- 
aged system in a management network with at least 
one managing system and at least one managed sys- 
tem, for telecom or open systems, said managed sys- 
tem consisting of subsystems forming each a part of the 
managed system including one or more managed 
objects. 

The managed objects are implemented in the sub- 
system, uncoordinatedly with respect to other subsys- 
tems, in such a way that they can be connected to and 
transmit messages to other objects in other subsys- 
tems, and without knowing the type of objects in the 
other subsystems. This is obtained by designing a first 
object (330) for co-operation with an abstract object 
(332) defining an interface consisting of unimplemented 
methods, which may be called by the first object, and 
letting, at later design of a second object (334) unknown 
to said first object and intended to co-operate with the 
first object, the other object inherit the abstract object 
and implement the inherited methods, so that the first 
object at co-operation with the second object will con- 
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